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Summary 

This  software  provides  a  moderately-realistic  simulation  of  a  shipboard  radar  tracking 
system,  such  as  AEGIS.  The  graphics  resemble  those  provided  on  the  large-screen 
display  of  the  AEGIS  system,  and  the  commands  which  can  be  issued  are  many  of 
those  available  to  the  decision-maker  commanding  a  CIC  team.  The  simulated  radar 
display  of  air  and  sea  tracks  are  updated  on  a  real-time  basis,  and  the  display  reflects 
movements  of  these  craft  in  real  time.  Depending  upon  the  scenario  conditions 
specified,  the  air  and  sea  craft  may  be  friendly  or  hostile,  and  they  may  or  may  not  react 
to  actions  taken  by  the  CIC  team.  A  wide  range  of  atmospheric  ^d  system  readiness 
conditions  can  be  established  for  any  individual  exercise.  In  addition,  the  various  craft 
may  be  set  up  to  execute  maneuvers  of  their  own,  i.e.,  not  in  response  to  actions  taken 
by  the  CIC  personnel.  The  individual  targets  may  be  configured  to  represent  virtually 
any  type  of  craft,  ranging  from  commercial  fishing  vessels,  private  helicopters,  or 
commercial  airliners  to  high-performance  military  aircraft. 

A  unique  feature  of  this  software  is  its  ability  to  be  easily  configured  by  a  non¬ 
programmer  to  simulate  a  wide  range  of  conditions  and  tactical  scenarios.  An 
experimenter  can  define  any  number  of  initial  conditions  as  well  as  within-problem 
actions  taken  by  the  various  ships  and  aircraft.  If  desired,  the  system  can  be  directed  to 
generate  problem  conditions  automatically,  so  that  human  participants  or  computer- 
based  decision  models  can  experience  hundreds  or  thousands  of  problems  with  very 
little  configuration  effort  on  the  part  of  the  experimenter.  The  system  also  supports 
research  in  machine  learning,  as  it  can  accept  decisions  of  an  external  software  system 
as  if  those  decisions  were  made  by  a  human  user. 

Finally,  the  system  provides  features  that  can  be  exploited  for  training.  One  such 
feature  allows  expert  tacticians  to  perform  recommended  responses  to  specific  tactical 
situations  and  to  distribute  these  completed  presentations  to  classrooms  or  to  the  fleet 
via  floppy  diskette.  Learners  or  instructors  can  then  replay  those  scenarios  at  renaote 
locations  to  observe  the  expert  performance,  and  to  attempt  to  emulate  them.  The  ability 
to  pause  and  resume,  as  well  as  control  the  speed  of  the  simulation  further  enables 
learners  and  instructors  to  examine  conditions  and  consider  alternatives  in  ways  the  true 
real-time  environment  tends  to  discourage. 
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Hardware  and  Operating  System  Requirements  I 

The  CIC  simulation  may  be  run  on  two  platforms:  j 

1.  PC  486  with  at  least  16  MB  RAM  (20  or  32  MB  is  better)  running  SCO  Unix  or 

Novell  UnixWare  Personal  Edition  VI. 1.  , 

The  screen  resolution  should  be  set  to  1024  x  768.  If  installing  Novell  UnixWare, 
contact  Novell  and  request  the  necessary  video  driver. 

2.  Sun  SPARCstation  I 
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Distribution  Files  and  Installation 


Files 

The  following  files  comprise  the  distribution: 

Platform-specific  simulation  engine  (vou  mav  receive  one  or  both  of  the  following): 
ridesSparc.Z  foruseonaSunSPARCstation  (2  diskettes) 

ridesPC.Z  for  use  on  an  IBM  compatible  PC  (2  diskettes) 


Platform-independent  files 
CIC 

CICDescriptions 

SessionPlan 

session) 

configl,  config2, .. 

portNames 

rides_defaults 


:  (1  diskette) 

(the  CIC  simulation  application) 

(editable  descriptions  of  various  aircraft  and  ships) 
(an  example  of  a  list  of  exercises  to  be  presented  in  a 

(some  predefined  example  configurations) 

(an  example  list  of  airport  names) 

(specifications  required  by  the  rides  system) 


Note;  File  names  in  Unix  are  case-sensitive. 
The  files  listed  above  must  be  named  as  shown. 


Of  the  above  files,  CICDescriptions,  SessionPlan,  and  portNames  are  fully  editable  by 
the  end  user  using  a  text  editor.  The  configx  files  are  modifiable  using  the  CIC 
configuration  authoring  features. 


To  Install: 

1.  Copy  the  file  ridesPC.Z  or  ridesSparc.Z  to  your  home  directory,  as  follows: 

a.  Put  diskette  #1  of  either  the  ridesPC.Z  or  ridesSparc.Z  set  into  the  floppy  dnve. 

b.  In  UnixWare  VI .  1  enter:  tar  xv<n>,  where  n  is  an  integer  representing 

the  floppy  drive  on  your  system,  e.g.,  tar  xv6 

c.  When  directed  to,  replace  floppy  #1  with  floppy  #2  of  the  set. 

2.  Rename  ridesSparc.Z  or  ridesPC.Z  to  rides.Z. 

3.  In  the  terminal  window,  enter  uncompress  rides 

4.  Copy  the  files  from  the  CIC  diskette  to  the  same  directory,  as  in  step  lb.  The  files 

may  then  be  moved  to  another  directory,  except  for  rides_defaults  which  should 
remain  in  the  home  directory. 

5.  The  simulation  functions  more  smoothly  if  you  place  this  line  in  the  file  .Xdefaults, 

found  in  your  home  directory: 

Mwm*resizeBorderWidth:  6 

Check  to  see  if  there  is  already  a  resizeBorderWidth  line  in  the  file:  if  so,  make  sure  the 
integer  given  is  6.  Otherwise,  add  this  line  to  the  file,  exactly  as  shown  (use  tab  or 
blanks  between  the  colon  and  the  6). 


3 


System  Startup 

To  start  the  simulation,  execute  rides  with  the  CIC  application.  In  the  UnixWare 
desktop  this  is  done  by  dragging  the  CIC  application  onto  the  rides  file  icon. 

(Sun  users  only;  Some  older  Sun  workstations  have  a  bug  in  X.  Try  using  openwin  to 
start  X  on  the  Sun,  rather  than  using  startx.) 

Wait  about  30  seconds,  until  the  mouse  icon  changes  from  a  watch  to  a  hand.  You  will 
now  see  a  start-up  screen  with  a  User  Name  field.  The  name  entered  here  determmes  m 
which  of  three  possible  modes  the  simulation  is  run: 

1  ■  data  collection  mode  .  ,  .  ..  . 

To  identify  a  human  participant  in  a  learning  exf^nment,  key  m  any  identification  name 
that  is  also  a  legal  file  name  in  your  system  (click  on  the  field,  key  in  the  name,  press 
the  Return  key).  The  name  may  be  the  participant  s  name,  or  it  could  be  an 
alphanumeric  code.  Then  click  on  the  Proceed  button.  Thereafter,  the  keyboard  is  not 
used  unless  the  user  has  been  given  access  to  certain  special  options.  The  screen  will 
then  display  the  simulated  radar  presentation,  various  buttons  used  to  operate  the 
simulated  system,  and  a  prompt  to  click  on  Begin  to  start  the  first  problein.  To  begin  a 
problem,  click  on  Begin.  The  system  will  then  present  problems  in  the  order  specified 
in  the  file  SessionPlan,  described  below. 

At  the  end  of  each  problem,  a  message  will  be  displayed  advising  the  user  that  the 
problem  has  ended,  and  to  click  on  Begin  to  start  the  next  problem.  Option^  y,  a 
performance  score  will  be  displayed,  and  the  user  may  be  allowed  to  examine  the  true 
identities  and  intentions  of  all  the  craft  involved  in  the  just-completed  exercise.  At  the 
end  of  the  final  exercise,  the  user  is  advised  that  the  session  is  complete. 

2.  authoring  mode  .  •  i  • 

To  author  new  tactical  exercises  (configurations)  or  modify  existing  scenarios,  key  in 
the  term  author  to  the  name  ID  field  (click  on  the  field,  key  in  author,  press  the  Return 
key).  Then  click  on  the  Proceed  button.  As  author,  you  may  define  and  save  scenano 
configurations  and  environmental  conditions,  retrieve  and  modify  previously  defined 
configurations,  and  run  problems.  The  file  SessionPlan,  described  below,  does  not 
control  the  session  in  authoring  mode,  and  it  is  not  referenced  by  the  system.  Author 
actions  in  working  trial  problems  are  written  to  the  single  file  named  author.  1  his  tile 
contains  data  just  for  the  previous  problem  worked.  Refer  to  the  section  entitled 
Authoring  Mode  for  further  authoring  details. 

3.  machine  learning  mode  .  .  i.- 

To  run  problems  to  be  worked  by  a  machine  learning  model,  key  in  machine  io  the 
name  ID  field  (click  on  the  field,  key  in  machine,  press  the  Return  key)  then  click  on 
Proceed.  Now,  the  system  will  automatically  run  the  problems  specified  in  the 
SessionPlan  file,  described  below. 

Quitting  the  Simulation 

To  exit  the  simulation  normally,  click  on  the  Quit  button  displayed  in  the  upper  left 
hand  comer  of  the  screen.  To  abort  a  mn  under  unexpected  conditions,  bnng  the  term 
window  to  the  front  and  press  the  Delete  key. 

The  three  mode  types  are  now  detailed  in  the  following  main  sections. 
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Data  Collection  Mode 

If  any  name  other  than  author  or  machine  is  entered  as  the  user  identification,  the 
simulation  runs  in  a  data  collection  mode.  In  this  mode,  the  system  presents  problems 
according  to  the  specifications  in  the  SessionPlan  file,  and  it  writes  out  performance 
data  to  files  named  <usemame>.x  where  username  is  the  user’s  identification,  and  x  is 
an  integer  signifying  the  problem  number,  e.g.,  smith.l,  smith.2,  smith.3.  The  format 
of  the  SessionPlan  file  is  provided  in  the  Authoring  section.  The  contents  of  the  user’s 
performance  data  file  is  provided  in  a  subsequent  section  (Task  Performance  Data). 

The  Simulation 

In  data  collection  sessions,  the  simulation  screen  appears  as  shown  in  Figure  1.  The 
major  components  on  this  screen  are  these: 

Utility  buttons,  to  Begin  and  Pause  problems. 

The  radar  display  representing  the  radar  screen,  showing  various  targets  and, 
depending  upon  the  radar  range  selected,  portions  of  the  surrounding  land  mass. 

Display  controls,  used  to  show  or  hide  various  elements  of  the  radar  graphics. 

Range  controls,  used  to  set  the  range  of  the  simulated  radar  system. 

The  Character  Read  Out  box,  which  displays  information  about  the  selected  target. 

Threat  Assessment  buttons  (Friendly,  Hostile,  Unknown),  used  to  classify  the  selected 
target  according  to  its  believed  threat 

User  action  buttons,  used  to  issue  orders  to  other  virtual  crew  members,  or  inquiries 
and  warnings  to  aircraft  and  ships. 

Elapsed  time  and  Local  time  indicators  which  display  the  elapsed  time  on  the  current 
exercise,  and  the  simulated  time  of  day  on  a  24-hour  clock.  Experimental  participants 
should  be  advised  that  the  simulated  time  of  day  may  be  quite  different  than  the  true 
time  of  day  at  their  location,  thus  visual  identifications  may  be  affected  by  the  available 
sunlight. 

User  Prompt  Box,  which  provides  directions  to  the  user,  such  as  “Click  on  Begin  to 
start  your  first  problem.”  This  box  is  also  used  to  prompt  the  author  during  authoring. 

Verbal  communication  display,  the  rectangle  below  the  radar  display,  in  which  all 
verbal  communications  are  displayed.  This  box  displays  the  verbal  commands  that  go 
out  as  a  result  of  selecting  a  user  action  button,  as  well  as  any  responses  from  the  crew 
or  from  contacted  ships  or  aircraft. 

Problem  number,  a  number  that  increases  from  1  to  the  number  of  problems  taken. 

Also  shown  at  the  end  of  each  problem,  if  requested  by  the  experimenter,  a 
performance  score  and  a  target  debriefing  box.  The  target  debriefing  box  appears  over 
the  verbal  communication  box,  and  displays  the  characteristics  of  any  selected  target. 
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Problem:  0 


Vnldantlflad  aircraft  on  a  couraa  of  283  dasroas, 

da,ra...  15  nlnuta.  .. 

^r  totaLloS  a“^t*claar,  raquaat  y®" 

Inmadlataly  altar  couraa  to  ranaln  claar  of  ay  position,  ovar. 


Figure  1.  The  CIC  Simulation  Screen. 
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User  Actions 


All  user  actions  are  made  via  the  left  mouse  button,  as  follows; 

Begin.  The  user  clicks  on  this  button  to  begin  a  problem.  In  response,  the  system  sets 
up  the  next  exercise  and  starts  the  clock. 

Pau.se.  If  visible,  this  button  is  used  to  temporarily  pause  a  problem  (stop  the  clock).  If 
a  problem  is  paused,  this  button’s  label  changes  to  Resume.  In  pause  mode,  the  user 
may  select  targets,  view  their  characteristics  in  the  Character  Read  Out  box  (see  below), 
change  the  displayed  radar  range,  or  change  any  of  the  Display  options.  The  system  can 
be  set  up  so  that  users  cannot  pause,  in  which  case  this  button  is  not  visible. 

Di.splav.  Clicking  on  any  of  the  five  check  boxes  toggles  the  visibility  of  the  listed 
display  element.  The  five  boxes  are  independent  of  one  another.  At  the  start  of  each 
problem,  the  Display  buttons  are  initialized  as  follows; 

Commercial  air  routes  unchecked  (not  visible) 

Commercial  air  schedules  unchecked  (not  visible) 

Velocity  leaders  checked  (visible) 

Missile  ship  circle  unchecked  (not  visible) 

Track  numbers  checked  (visible) 


Range.  Clicking  on  any  of  the  five  radio  buttons  sets  the  outer  circle  of  the  radar 
display  to  the  range  selected,  in  miles. 

Target  Sf-lections.  The  user  selects  a  particular  target  displayed  in  the  radar  area  by 
clicking  on  it.  In  response  to  this  an  audible  beep  sounds,  a  red  circle  is  displayed 
around  the  selected  target,  and  the  target’s  characteristics  are  displayed  in  the  t^le 
displayed  to  the  left  of  the  radar  display.  This  box,  called  the  Character  Read  Out 
(CRO)  provides  information  about  the  target  such  as  its  track  number,  beanng, 
heading,  speed,  etc.  The  values  in  this  table  change  over  time  as  the  selected  target 
moves. 

Each  target  sensed  by  the  (simulated)  radar  is  displayed  according  to  its  type  (aircraft, 
surface  vessel,  submarine),  and  its  threat  assessment  (friendly,  hostile,  unknown). 
Thus  there  are  9  possible  symbols  for  targets,  as  follows; 


Threat  Assessment 

Unknown 

Friendly 

Hostile 

Air 

m 

Surface 

□ 

O 

0 

Sub-surface 

LJJ 

\/ 

The  threat  assessment  of  a  target  is  initially  established  in  a  problem  s  configurate^ 
this  represents  the  initial  determination  that  has  been  assigned  each  target  by  toe  CIC 
crew  using  the  AEGIS  system.  These  initial  designations  may  be  correct  (all  fnendly 
and  hostile  designations  are  correct),  vague  (many  unknown  designations),  or  incorrect 
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(one  or  more  targets  incorrectly  designated  as  friendly  or  hostile).  The  threat 
designation  of  any  target  may  be  changed  thereafter  by  the  user  to  maintain  a  visual  cue 
of  his  or  her  beliefs. 

In  addition,  a  target  has  a  track  number  designation,  a  4-digit  nuniber  assigned  to  the 
target  for  that  exercise,  and  a  velocity  leader,  a  line  whose  direction  indicates  the  current 
heading  of  the  target  and  whose  length  designates  the  current  speed  of  the  target.  As 
with  the  actual  AEGIS  system,  the  relation  between  the  length  of  the  velocity  leader  and 
the  target’s  speed  is  nonlinear,  so  that  small  velocities  can  be  seen,  and  large  velocities 
do  not  overwhelm  the  display.  The  track  number  and  velocity  leader  can  be  made 
visible  or  invisible  by  the  user.  The  following  display  is  a  friendly  ship,  designated  as 
track  number  1073,  traveling  in  a  south-easterly  direction. 


The  simulation  comes  stocked  with  four  kinds  of  targets  (see  Appendix  A): 

1.  aircraft 

2.  surface  vessels 

3.  subsurface  vessels 

4.  clutter  (distracting  radar  images  that  appear  to  be  real) 

(Clutter  targets  appear  as  friendly  air  targets,  with  0  speed  and  0  altitude) 

A  particular  exercise  may  involve  any  subset  of  the  available  targets,  each  target 
configured  per  the  requirements  of  the  experimenter. 

All  user  actions  listed  below  pertain  to  the  selected  target.  All  user  actions  that  are 
orders  to  other  crew  members  will  produce  textual  orders  in  the  verbal  communication 
box,  after  some  delay.  After  an  additional  delay,  some  of  the  commands  may  produce 
responses  from  contacted  targets  or  land-based  towers.  See  appendix  B  for  the  buut-m 
delays  that  pertain  to  the  user  actions.  _  _ 

Friendly.  Unknown.  Hostile.  The  user  clicks  on  these  buttons  to  designate  the  threat  of 
the  currently  hooked  target  as  being  friendly,  unknown,  or  hostile.  In  response,  the 
system  changes  the  graphic  symbol  representing  the  selected  target  to  correspond  to  the 
current  threat  assessment. 

ripar  Target  Disnlav.  The  user  clicks  on  this  button  to  make  the  selected  target 
disappear.  This  can  be  done  to  eliminate  distracting  clutter  targets. 

Rp.stnre  Tareet.  The  user  clicks  on  this  button  to  make  previously  cleared  targets 
reappear.  Each  click  of  this  button  restores  the  display  of  a  previously-cleared  target, 
working  from  the  most  recently  cleared  to  the  first  cleared  target,  for  that  problem. 

rnniactTower.  The  user  clicks  on  this  button  to  get  in  touch  with  a  land-based  control 
tower  to  determine  if  the  hooked  target  might  be  a  commercial  airliner.  The  particuw 
tower  contacted  is  not  explicitly  identified;  it  is  assumed  that  the  appropriate  tower  is 
contacted.  When  the  Contact  Tower  button  is  pressed,  a  verbal  inquiry  is  sent  to 
determine  if  the  hooked  target  might  be  a  commercial  airliner,  under  control  of  the 
tower  If  there  is  a  commercial  air  liner  in  the  vicinity  of  the  hooked  target  (position 
within  5  miles  of  the  hooked  target  and  altitude  within  5,000  of  hooked  target),  a 
response  will  be  received  to  that  effect,  after  some  delay.  Otherwise,  the  tower  will 
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respond  that  there  is  not  a  commercial  airliner  in  the  vicinity  indicated  by  the  hooked 
target.  Thus,  if  there  are  two  or  more  aircraft  flying  in  a  close  group,  one  of  which  is  a 
commercial  airliner,  the  tower  will  confirm  presence  of  an  airliner  in  the  area  of  the 
hooked  target,  even  if  the  hooked  target  does  not  happen  to  be  the  airliner  itself. 

Rpfpipxt  Visual  TD.  The  user  clicks  on  this  to  command  the  bridge  to  attempt  to  make  a 
visual  identification  of  the  selected  target.  The  bridge  will  respond  with  an 
identification,  after  some  delay,  if  the  following  conditions  are  all  true: 

The  local  time  is  between  6  A.M.  and  6  P.M.  (i.e.,  it  is  daylight). 

The  target’s  altitude  is  less  than  the  ceiling  for  the  problem. 

The  target’s  range  is  less  than  50  miles  and  less  than  the  visibility  for  the  problem. 

niiiminate  Target.  The  user  clicks  on  this  to  ‘illuminate’  the  selected  target.  This  action 
alerts  the  selected  target  that  it  is  being  acquired  for  defensive  action,  and  also  serves  as 
a  drastic  warning  to  a  target  that  is  not  responding  to  radio  warnings.  After  some  delay, 
an  illuminated  target  will  turn  away  from  the  ship  if  1)  it  is  configured  as  one  which 
will  heed  warnings,  2)  it  is  within  30  miles  range,  and  3)  it  is  an  aircraft  whose  IFF 
mode  is  1,2,  or  4. 

Fire.  Warning  Shots.  The  user  clicks  on  this  to  fire  warning  shots  at  the  selected  target. 
The  target  will  turn  away  from  the  ship  if  1)  the  target  is  configured  as  one  which  will 
heed  warnings,  and  2)  the  target  range  is  less  than  5  miles. 

Defend  Ship.  The  user  clicks  on  this  to  command  the  crew  to  take  defensive  action 
against  the  selected  target.  There  is  not  a  simulation  of  the  weapons  hitting  or  missing 
the  target,  thus  this  action  should  usually  be  one  which  terminates  problems. 

Warning.  The  user  clicks  on  any  of  these  six  buttons  to  issue  a  radio  warning  to  the 
selected  target.  Warnings  are  at  three  possible  levels,  and  may  be  issued  on  two 
possible  radio  bands:  (1)  Military  Air  Distress  (MAD),  and  (2)  International  Air 
Distress  (lAD). 

The  selected  target  will  receive  the  warning  if  the  following  are  aU  true: 

•  the  ship’s  transmitter  is  operational  (if  limited  range,  target  must  be  within  10  miles); 

•  the  target  is  monitoring  the  band  upon  which  the  warning  was  sent  (MAD  or  lAD); 

•  the  target’s  receiver  is  operational. 

The  target  will  turn  away  from  the  ship,  after  some  delay,  if:  1)  the  target  receives  the 
warning,  2)  the  warning  is  issued  at  level  2  or  3,  and  3)  the  target  is  configured  as  one 
which  heeds  warnings.  The  target’s  verbal  response  to  the  warning  will  be  displayed  in 
the  verbal  communication  box  if:  1)  the  target  receives  the  warning,  2)  the  target  s 
transmitter  is  operational,  and  3)  the  ship’s  receiver  is  operational.  If  desired,  the 
experimenter  may  set  the  target’s  verbal  response  to  be  silence  by  creating  a  line  in 
CICDescriptions  that  contains  “  “,  and  setting  the  target’s  selfID  to  that  line  number. 

Task  Performance  Data 

The  details  of  each  exercise  run  in  data  collection  mode  are  written  chronologic^ly  to  an 
ASCn  format  data  file.  The  file  created  for  the  first  exercise  run  by  user  Smith  is  named 
Smith.  1,  the  second  is  Smith.2,  etc.  To  minimize  the  data  loss  if  a  power  outage  or 
other  failure  should  occur,  each  exercise  is  written  to  a  separate  data  file.  The  data  file 
contains: 
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•  problem  specs  —  user  ID,  problem  number,  time  and  date  of  problern  presentation, 
scenario  name,  environmental  conditions,  list  of  active  target  types, 
file  write  interval,  and  number  of  active  targets  and  clutter  targets. 


•  periodic  updates  —  the  positions,  speeds,  etc.  of  each  target  at  each  update  time; 


•  user  actions  —  overt  actions  made  by  the  user; 

•  replies  —  radio  messages  received  from  targets,  towers,  and  other  crew  members; 

•  end  marker  —  a  record  coded  99,  followed  by  seconds  since  start  of  problem,  and 

the  user’s  performance  score. 

Problem  Specs 

Each  exercise  file  is  headed  with  sufficient  information  to  completely  replay  the 
problem  (given  that  the  scenario  file  originally  used  is  still  available).  This  header 
information  provides  the  following: 


1 .  title:  The  name  of  this  data  file 

i.  date  and  time  of  file  creation  (time  may  be  in  error  on  some  installations) 

3.  scenario  name  Name  of  scenario  configuration  file 

4.  environment  data  (16  characters,  total) 


001,005,010,025,  or  100  (thousand  feet) 
01,05,10,20,30  (miles) 

0,1, 2,3  (failed,  OK,  intermittent,  limited  range) 
0,1, 2,3  (failed,  OK,  intermittent,  limited  range) 
like  “18:30” 


ceilingButtons  (3): 
visibilityButtons  (3): 
recvrButtons  (2): 
xmtrButtons  (2): 
local  time  (6): 

5.  file  write  interval,  in  seconds 

6.  number  of  active  targets  (2  chars),  number  of  active  clutter  targets  (2  chars) 


Problem  Data 

Problem  data  are  written  to  the  file  as  the  problem  progresses.  Data  are  of  three  types: 

(1)  periodic  updates  which  reflect  the  status  of  each  target  at  a  particular  time; 

(2)  user  actions,  written  whenever  the  user  makes  an  overt  action,  and 

(3)  replies,  written  whenever  a  reply  is  received  to  some  command  or  inquiry. 

Each  record  starts  with  a  2-digit  code  as  listed  in  the  table  below.  Following  each  code 
is  the  time  at  which  the  action  took  place,  in  seconds,  after  start  of  problem.  For  all 
record  types  except  periodic  update,  this  is  followed  with  the  track  number  of  the  target 
involved. 


An  example  record  appears  as  follows: 


05  0083  1244  ,  ^ 

This  record  states  that  the  user  fired  warning  shots  near  target  1244,  83  seconds  into 


the  problem. 
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code 


01 


02 


03 


04 


05 


06 


07 


08 


09 


10 


11 


12 


13 


14 


15 


16- 

29 


30 


31^9 


50 


60 


activit' 


riodic  target  update _ 


hook  (select)  a  target _ _ _ _ _ 


warn  the  hooked  target  _ _ _ 


the  warned  target  replies  _ 


fire  warning  shots  near  the  hooked  target _ 


illuminate  the  hooked  target  _ _ 


reouest  visual  ID  of  the  hooked  target  _ _ 


receive  visual  ID  of  hooked  target  from  bridge 


contact  the  tower  regarding  the  hooked  target 


receive  information  from  tower  regarding  hooked  target 


change  threat  assessment  of  hooked  target _ 


open  _ _ _ 


open  _ 


clear  hooked  target  display  from  screen  _ 


restore  last  cleared  target  _ 


—  open  — 

change  display  (comm’l  air  routes, radar  range) 


a  hostile  target  fires  at  own-shi 


own-ship  fires  at  hooked  target 


end  of  problem,  plus  user’s  performance  score _ 


Codes  for  Performance  Data  Files 


Periodic  Updates  (code  01) 

Periodic  updates  are  signified  by  a  record  coded  01,  followed  by  the  time  at  which  the 
update  applies.  This  record  is  followed  by  a  number  of  sub-records,  each  of  which 
describes  the  condition  of  one  active  target,  at  that  time. 

The  periodic  updates  provide  all  pertinent  information  about  the  situation  at  a  p^cular 
instant.  A  periodic  update  is  automatically  written  when  the  problem  starts.  This  initial 
update  provides  data  about  all  the  active  targets,  including  any  clutter.  Thereafter,  a 
periodic  update  is  written  each  S  seconds,  where  S  can  be  set  by  the  experimenter. 
These  subsequent  updates  do  not  list  the  clutter  targets  again,  as  they  never  change 
position.  A  final  update  is  written  to  reflect  terminating  conditions. 

At  each  update  time,  a  record  is  written /or  each  active  target  expressing: 
track  number 

bearing  from  own  ship,  in  degrees 
range  from  own  ship,  in  miles 
altitude,  in  feet 
speed,  in  knots 

heading,  in  degrees  „ .  i  x 

current  threat  assessment  (u,  f,  or  h  for  unknown,  friendly,  or  hostile  respectively) 
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Example  Periodic  Update 

01  30  (this  periodic  update  describes  the  problem  status  after  30  seconds) 

1024  045  044  001000  0445  124  u  (the  first  active  target) 

1144  150  018  024500  0266  090  h 

1010  018  009  000000  0012  242  f 

1211  268  029  021432  0388  074  f 

1095  111  006  000000  0022  167  u  (the  5th  active  target) 

User  Actions  (codes  02,  03,  05,  06,  07,  09,  11,  14,  15,  and  60) 

Each  user  action  is  recorded  with  a  code  that  indicates  what  the  action  was,  the  time  at 
which  the  action  was  performed,  and  the  target  involved  (always  the  currently  hooked 
target).  In  addition,  a  few  of  the  action  types  produce  an  additional  character  to  further 
describe  the  situation. 

HnnV  target  (code  021  This  record  type  ends  with  a  2-digit  number  that  is  used  by  the 
Replay  function  within  the  simulation  system: 

02  12  1024  04  (hook  target  1024, 12  seconds  into  the  problem) 

Warn  hooked  target  tcode  031.  This  record  type  reflects  the  level  at  which  the  warning 
was  issued  and  the  radio  band  on  which  the  warning  was  issued— (1)  military  or  (2) 
international  air  distress: 

03  29  1024  21  (warn  target  1024,  29  seconds  into  the  problem,  a  level  2 

warning  (2),  on  Military  Air  Distress  (1). 

Fire  warning  shots  (code  05). 

05  34  1024  (fire  warning  shots  near  target  1024,  34  seconds  into  the 

problem.) 

Tlluminate  hooked  target  (code  06). 

06  50  1024  (illuminate  target  1024,  50  seconds  into  the  problem.) 

Request  visual  ID  of  hooked  target  (code  07). 

07  55  1024  (request  visual  ID  of  target  1024,  55  seconds  into  the  problem.) 

Contact  tower  regarding  hooked  target  (code  09). 

09  60  1024  (contact  tower  regarding  target  1024,  60  seconds  into  the 

problem.) 

Change  threat  assessment  of  hooked  target  (code  1 1^ 

11  65  1024  friendly  (change  assessment  of  target  1024  to  friendly) 

(other  codes  are  “hostile”  and  “unknown”) 

Clear  hooked  target  from  display  (code  14). 

14  75  1024  (clear  target  1 024  from  screen,  at  75  seconds. ) 

Restore  hooked  target  on  screen  (code  15). 

15  85  1024  (restore  display  of  target  1024,  at  85  seconds.) 

Fire  at  hooked  target  (code  60). 

60  95  1024  (fire  at  target  1024,  at  95  seconds.) 
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Replies  and  Target  Actions  (codes  04,  08,  10,  50) 

The  remaining  codes  refer  to  actions  by  other  crew  members  and  by  targets. 

The  warned  target  replies  (code  04) 

04  69  1024  (target  1024  identifies  itself  in  response  to  warning,  at  69 

seconds)  This  record  is  not  written  if  the  user  does  not  receive  a  verbal  response  from 
the  warned  target  (because  of  equipment  malfunctions).  The  nature  of  the  self 
identification  is  whatever  the  experimenter  established  for  the  warned  target. 

The  bridge  responds  with  a  visual  ID  attempt  (code  08) 

08  77  1024  y  (the  bridge  responds  with  visual  ID  of  target  1 024  at  77  seconds) 

The  code  ‘y’  signifies  that  the  bridge  was  able  to  make  some  kind  of  identification  of 
the  target,  the  nature  of  which  is  whatever  the  experimenter  established  for  that  target. 
Alternatively,  the  code  ‘n’  signifies  that  the  bridge  was  not  able  to  make  an 
identification  due  to  excess  range,  poor  light,  or  atmospheric  conditions  (or  the  target 
was  clutter). 

The  tower  responds  (code  10) 

10  87  1024  y  (the  tower  responds  concerning  target  1024  at  87  seconds) 

The  code  ‘y’  signifies  that  the  tower  verifies  that  the  tower  is  controlling  a  commercial 
airliner  in  the  vicinity  of  (within  5  miles)  the  hooked  target  and  within  5,000  feet  of  its 
altitude.  Alternatively  the  code  ‘n’  signifies  that  the  tower  denies  that  it  has  control  of  an 
airliner  in  the  position  and  altitude  indicated  by  the  user. 

A  target  fires  on  own  ship  (code  50) 

50  97  1024  (target  1024  fires  on  own  ship  at  97  seconds) 

Changes  to  the  Simulation  Display  (code  30) 

Code  30  signifies  that  the  user  changed  some  element  of  the  simulation  Display.  For 
consistency  and  ease  of  data  analysis,  this  record  type  is  in  the  same  format  as  all  other 
data  records,  although  the  track  number  of  the  hooked  target  has  no  real  bearing  on  this 
record  type.  Following  the  hooked  target  track  number  is  one  blank  and  then  digits  that 
indicate  which  type  of  display  element  was  changed,  and  its  new  value. 

The  characters  following  the  hooked  target  track  number  are  these: 

1  changed  visibility  of  commercial  airline  routes 

2  changed  visibility  of  commercial  airline  schedule 

3  changed  visibility  of  velocity  leaders 

4  changed  visibility  of  missile  ship  circle 

5  changed  visibility  of  track  numbers 

6  changed  radar  range 

Following  the  digits  1  through  5  is  a  blank  and  then  ‘v’  or  ‘i’  to  indicate  that  the  display 
element  is  visible  or  invisible.  Following  digit  6  is  a  blank  and  the  new  radar  range,  as 
a  3-character  number. 


Examples 
30  107 

1024 

1 

V 

30 

147 

1024 

2 

i 

30 

153 

1024 

6 

016 

(user  sets  commercial 
(user  sets  commercial 
(user  sets  radar  range 


air  routes  to  visible) 
air  schedule  to  invisible) 
to  16  miles) 
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An  output  file  for  an  exercise  might  look  like  the  following: 


P28.7 

Thu  Sep  8  00:08:48  1994 
Of fCourseAirLiner 
001  30  1  1  12:30 
10 
4  1 

1024  045  044  001000  0445 


(participant  P28,  problem  number  7) 

(date  and  time  exercise  was  run) 

(name  of  configuration  for  this  exercise) 
(environmental  conditions) 

(file  write  interval,  seconds) 

(number  real  targets,  number  clutter  targets) 
124  u  (initial  conditions  of  the  5  targets) 


1134 

150 

018 

024500 

0266 

090 

u 

1543 

018 

009 

000000 

0012 

242 

f 

1754 

268 

029 

021432 

0388 

074 

u 

7001 

111 

006 

000000 

0000 

000 

f  (this  clutter  target  will  not  be  listed  again) 

02 

8 

1134 

06 

(hook  target  1 134,  8  seconds  into  exercise) 

01 

10 

(periodic  update  at  10  seconds) 

1024 

045 

043 

001050 

0445 

124 

u 

1134 

151 

018 

024800 

0266 

090 

u 

1543 

018 

009 

000000 

0012 

245 

f 

1754 

265 

030 

021432 

0388 

075 

u 

02 

19 

1754 

24 

(hook  target  1754  at  19  seconds) 

01 

20 

periodic  update  at  20  seconds) 

1024 

045 

043 

001050 

0445 

124 

u 

1134 

151 

018 

024800 

0266 

090 

u 

1543 

018 

009 

000000 

0012 

245 

f 

1754 

265 

030 

021432 

0388 

075 

u 

03 

37 

1754 

21 

(warn  target  1754) 

04 

69 

1754 

(target  1754  replies  to  warning) 

07 

85 

1754 

(request  visual  ID  of  target  1754) 

30 

103 

1024 

6  016 

(user  sets  radar  range  to  16  miles) 

08 

107 

1754 

Y 

(bridge  returns  visual  ID  of  target  1754) 

99 

480 

120 

(end  of  problem  at  480  seconds,  score  120) 
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Authoring  Mode 

To  author  exercises,  start  the  system  using  the  name  author.  This  allows  certain 
keyboard  commands  to  be  made,  and  it  provides  access  to  a  scenario  configuration 
screen  which  is  unavailable  to  experiment  participants. 

Prior  to  running  an  exercise,  the  author  may  specify  and  save  one  or  more  sets  of  initial 
conditions.  Additionally,  the  author  may  specify  sets  of  scheduled  maneuvers.  These 
are  real-time  changes  in  headings,  speeds,  and  altitudes  of  various  crafts  that  are  not  a 
result  of  the  user’s  actions. 

Then,  when  the  author  clicks  on  Begin,  the  system; 

1.  restores  the  conditions  of  the  latest  configuration  recalled  by  the  author; 

2.  reads  in  the  latest  scheduled  maneuvers  recalled  by  the  author,  if  any;  and 

3.  starts  the  exercise  running. 

The  author’s  actions  on  each  exercise  are  written  to  the  file  named  author ,  with  data  for 
each  problem  replacing  the  prior  data. 

Thus,  an  exercise  can  be  run  multiple  times,  each  time  starting  with  the  same  conditions 
and  each  time  involving  the  same  scheduled  maneuvers.  Alternatively,  the  author  can 
recall  different  conditions,  and  can  modify  and  save  different  problem  condiuotis.  To 
change  conditions,  follow  the  instructions  below,  then  save  the  revised  configuration. 


Backing  Up  Exercise  Configurations 

Configurations  represent  a  considerable  effort  invested  in  establishing  useful 
experimental  conditions.  Consequently,  they  should  be  backed  up  to  diskette  in  c^e  of 
hard  disk  failures  or  inadvertent  changes  caused  by  accidentally  saving  to  an  existing 
configuration  name. 

Exercise  Creation  or  Modification 

An  exercise  is  specified  in  terms  of  1)  initial  conditions  and  2)  optional  scheduled 
maneuvers  of  targets.  These  two  sets  of  information  are  independent,  thus  an 
experimental  trial  can  involve  any  selected  initial  scenario  configuration,  and  any 
selected  specification  of  scheduled  maneuvers,  or  none. 

Initial  Conditions 

Initial  conditions  (scenario  configurations)  are  established  by  1)  specifying  the 
characteristics  of  the  various  targets  that  will  be  involved  in  the  scenario,  and  2)  setting 
external  conditions  by  making  selections  on  the  Scenario  Configuration  screen  for  such 
factors  as  weather  and  the  operabihty  of  the  simulated  communication  equipment  of  the 
user’s  ship.  Target  characteristics  include  such  factors  as  target  positions,  headings, 
speeds,  altitudes,  intentions,  and  equipment  operability. 

Any  unique  set  of  initial  conditions  can  be  saved  in  a  file  named  by  the  author.  The 
configuration  name  is  not  seen  by  the  participant,  thus  it  can  be  descriptive  of  the 
situation,  such  as  terroristAttack,  ojfCourseAirliner,  orfailedReceiver. 
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Setting  Initial  Scenario  Conditions 

The  general  steps  in  defining  initial  scenario  conditions  are  these: 

1.  Press  ‘s’  to  move  to  the  Scenario  Configuration  screen  (Figure  2),  and  enter  the 
name  of  the  configuration  that  is  most  similar  to  the  one  to  be  specified  into  the  Get 
Scenario  box  (click  in  the  box,  key  in  the  file  name,  press  Enter).  See  Appendix  D  for 
the  names  of  the  configurations  supplied  with  the  system. 


Scenario  Configuration 


Own  Ship  System  Readiness 

SiV 

^31 

Local  Time  at  Start: 


Termination  Conditions 

A.  etap&ad  Sme> 

8,  ownebipfiree 

w 

•••1 

a  own  eblpflred  upon 
jO.  mtijgie  of  oeareat  threat  < 

_ 

o 

hue 

AofSorOofOietrae  . 

# 

Data  Fiie  Write  Interval:  —  Seconds 

Save  as  Scenario: 

Get  Scenario: 

Get  Fiight  Pian: 

Figure  2.  The  Scenario  Configuration  Screen 
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Press  ‘s’  again  to  return  to  the  simulation  screen.  All  the  visible  (active)  targets  for  the 
retrieved  configuration  are  seen  in  their  initial  positions  on  the  radar  screen.  The 
remaining  (inactive)  targets  are  initially  invisible. 

2.  To  bring  a  new  target  into  the  simulation,  first  make  the  inactive  targets  visible  by 
pressing  the  ‘v’  key.  Now  four  ‘stacks’  of  targets  will  be  seen  below  the  radar 
circle,  one  stack  for  each  type  of  target  (air,  surface,  subsurface,  clutter). 

To  bring  in  a  new  target: 

a.  click  on  the  stack  holding  the  target  type  desired.  This  will  select  the  top  target  of 

that  type.  ...  ^  .u 

b.  hold  down  the  ‘m’  key  (for  move)  and  click  on  the  radar  screen  where  the 

selected  target  should  be  positioned.  The  selected  target  will  move  to  that 
position.  Further  refinements  in  position  can  be  made  at  any  time  by  selecting  a 
target  then  clicking  at  its  new  position  with  the  ‘m’  key  depressed. 

To  ‘remove’  a  target  from  a  scenario,  move  it  from  the  radar  screen  back  to  its  stack 
(again,  click  on  the  target,  then  click  on  its  stack  while  holding  down  the  ‘m’  key). 

3.  For  each  active  real  target  (i.e.,  not  clutter),  set  its  speed,  altitude  (if  air),  and 
heading  by  doing  the  following: 

a.  press  the  f  key  (for  fly-by-wire),  and  observe  the  following  control  box: 


b.  Slide  the  Time  control  to  zero  (this  is  very  important). 

c.  Select  a  target  by  clicking  on  it  (clutter  targets  cannot  be  configured). 

d.  Operate  the  three  controls  to  establish  the  target’s  speed,  heading,  and  altitude. 
The  target  will  respond  instantly  to  these  controls. 

e.  Repeat  steps  c  and  d  for  all  non-clutter  targets. 

When  all  targets  have  been  set  up,  press  the  f  key  to  make  the  ‘fly-by-wire’  controls 
disappear. 

4.  Specify  the  behaviors  and  characteristics  of  the  active  targets  by  doing  the  following: 

a.  Press  the  c  key  (for  configure  target). 

b.  Select  a  target  by  clicking  on  it.  .  j  u  i 

c.  Make  selections  and  entries  in  the  target  configuration  box,  as  detailed  below. 

d.  Repeat  steps  b  and  c  for  all  targets. 
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When  all  targets  have  been  configured,  press  the  c  key  to  make  the  configuration  box 
disappear. 

5.  When  the  initial  target  conditions  are  as  desired,  move  to  the  Scenario  Configuration 
screen  by  pressing  the  s  key.  Set  the  Atmospheric  Conditions,  Own  Ship  Readiness, 
Local  Time,  Termination  Conditions,  and  Data  File  Write  Interval  as  detailed  below. 

6.  Save  the  scenario  configuration  by  entering  a  name  to  the  Save  as  Scenario  box. 
(click  on  the  scenario  name  box,  key  in  a  legal  file  name,  press  Enter).  When  the 
Enter  key  is  pressed,  the  target  characteristics  set  in  steps  2  through  4  and  the 
external  conditions  set  in  step  5  are  written  to  the  file  you  have  specified  as  the 
scenario  configuration  name. 

7.  Run  the  exercise  by  returning  to  the  simulation  screen  (press  s)  and  clicking  on 
Begin.  The  label  of  the  Begin  button  changes  to  Stop,  and  the  clock  starts  to  run. 

As  an  author,  you  can  halt  a  problem  by  clicking  on  Stop,  or  pause  a  problem  at  any 
time.  Each  time  an  author  clicks  on  Begin,  the  system  restores  the  latest  configuration 
saved  or  retrieved,  and  starts  the  simulation  running  in  real  time. 


Important  Note:  . 

If  an  author  gets  a  configuration,  then  makes  some  changes,  then  clicks  on  Begin, 
the  problem  will  run,  starting  at  that  newly  revised  condition.  That  condition  is  lost, 
however,  unless  the  author  saves  the  modified  configuration  prior  to  running  the 
problem. 


The  following  provides  more  detail  on  the  steps  outlined  above. 

Configuring  Individual  Targets 

The  simulation  comes  stocked  with  a  fixed  number  of  surface  vessels,  submarines, 
aircraft,  and  clutter  (see  Appendix  A).  Each  of  these,  generically  called  ‘targets’, 
maintains  its  inherent  type  for  all  time,  i.e.,  an  author  cannot  change  a  ship  into  an 
aircraft  Each  target  carries  a  unique  ‘t’  number  that  identifies  it.  Only  the  author  can  see 
this  reference  ID,  in  the  Target  Configuration  box,  described  below. 

Authors  can  shape  each  target  within  its  own  class.  For  example,  target  TOl  could  be  a 
helicopter  in  one  scenario,  and  a  jet  fighter  in  another  configuration.  Specifications  for  a 
particular  target  apply  to  the  configuration  in  which  that  target  is  saved,  i.e.,  a  target 
may  be  used  differently  in  different  configurations. 

Clutter  targets  need  not  be  configured  by  the  author;  they  are  preset  to  appear  as 
aircraft-type  symbols  on  the  screen,  but  they  will  not  respond  to  any  commands,  they 
cannot  be  seen  when  a  visual  ID  is  attempted,  nor  will  they  move  about. 

To  set  the  characteristics  of  targets  (step  4  above)  press  the  c  key  (for  configure).  The 
following  box  will  appear  (if  a  target  is  already  selected,  its  characteristics  will  display 
in  the  box,  otherwise  the  data  in  the  box  will  be  blank). 

Select  the  target  to  be  specified,  and  observe  its  current  characteristics. 

Boxes  containing  numbers  are  set  by  clicking  in  the  box,  keying  in  a  number,  then 
pressing  Enter.  Boxes  containing  OK  or  yes/no  or  checks  are  set  by  clicking  in  the  box. 


18 


Target:  t02  air _ 

Self  ID:  1 01 1  small  private  aircraft 
Visual  IPj  021  military  fighter 
Identity:  I  021  military  fighter 
Will  Fire  lyesj  Will  Heed  Wamingf^ 
IFF  ModePsI  IFF  Code:  [iMIl 
Receiver:  I  OKI  Transmitter: 

Monitoring:  lADEl  MADQ 


Track  CM! 


Self  ID,  Visual  ID,  and  Identity  all  refer  to  verbal  descriptions  contained  in  the  ASCII 
file  named  CICDescriptions.  These  are  not  used  for  clutter  targets,  thus  it  doesn’t 
matter  what  text  is  displayed  here  for  a  clutter  target.  The  entry  is  the  line  number 
in  this  file  that  contains  the  verbiage  desired.  This  file,  CICDescriptions,  can 
be  edited  and  extended  to  establish  any  verbal  descriptions  desired.  Each  description 
must  be  one  line  in  the  file. 

In  the  example  shown  above,  line  1  of  CICDescriptions  contains  the  phrase 

small  private  aircraft 

while  line  2  contains  the  phrase 

military  fighter 

Self  ID  is  the  response  a  target  returns  to  the  ship  when  asked  to  identify  itself.  If 
desired,  this  could  refer  to  a  record  in  the  CICDescription  file  that  contains  “  “,  i.e., 
silence.  The  Self  ID  can  be  truthful  or  devious. 

Visual  ID  is  the  response  given  when  the  bridge  is  successful  in  making  a  visual  ID. 
Generally,  this  is  a  general  description,  such  as  “military  aircraft”  or  “commercial 
vessel”. 

Identity  is  the  true  identification  of  the  target. 

K  a  number  is  entered  for  any  of  the  above  three  which  is  greater  than  the  number  of 
lines  in  the  CICDescriptions  file,  the  text  shown  will  be  **  EOF  **  (End  of  File). 

Will  Fire  specifies  whether  the  target  will  fire  on  the  ship  or  not  (i.e.,  whether  it  is 
hostile).  See  IFF  Mode,  below,  for  the  range  at  which  various  targets  will  attack.  Once 
one  target  has  fired  on  own  ship,  within  a  problem,  no  other  targets  will  fire. 
Generally,  a  target  firing  on  own  ship  should  terminate  a  problem. 
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Will  Heed  Warning  specifies  whether  the  target  will  heed  warnings  that  it  receives. 
A  target  can  be  set  up  as  hostile  (will  fire),  but  to  heed  warnings  if  it  receives  them. 
This  represents  a  target  that  will  attack  if  possible,  but  not  unless  it  thinks  it  is  safe  to 
do  so.  A  hostile  target  that  will  not  heed  warnings  will  attack  whether  warned  or  not. 

IFF  Mode  is  a  digit  (0,  1,  2,  3,  or  4)  which  describes  the  target  to  the  simulation 
system.  This  should  be  set  to  0  for  non-military  ships  and  aircraft;  to  1,  2,  or  4  for 
military  ships  and  aircraft;  and  to  3  for  commercial  airliners.  This  digit  is  used  along 
with  the  target  type  (surface,  air  or  subsurface)  to  determine  whether  or  not  it  senses 
being  illuminated,  and  the  range  at  which  it  would  fire  on  the  user’s  ship,  if  it  is  hostile. 

The  simulation  system  uses  IFF  mode  as  follows: 

Only  military  aircraft  (IFF  mode  1, 2,  or  4)  can  sen^  being  illuminated. 

Only  commercial  airliners  (IFF  mode  3)  are  recognized  by  the  land-based  tower. 
Hostile  ships  and  aircraft  with  IFF  mode  0  attack  within  2  mile  range. 

Hostile  ships  and  aircraft  with  IFF  mode  1, 2,  or  4  attack  at  10  miles  range. 

Thus,  IFF  mode  0  describes  a  small  non-military  craft  that  could  carry  a  weapon  of 
some  limited  type. 

IFF  Code  is  currently  unused. 

Receiver  and  Transmitter  refer  to  the  operability  of  the  target’s  radio  equipment. 

By  clicking  on  this  field,  for  either  Receiver  or  Transmitter,  the  value  will  cycle  through 
the  following  values: 

OK 

intermittent  (works  half  the  time) 
limited  range  (10  miles  effective  range) 
failed 

Monitoring  specifies  which  radio  bands  are  monitored  by  the  target.  None,  one,  or 
both  boxes  may  be  checked  (checked  means  the  band  is  monitored  by  the  target). 

Track  is  the  track  number  to  use  for  the  target.  This  is  the  4-digit  number  that  will 
appear  on  the  radar  screen  for  that  target.  Use  track  numbers  7xxx  for  clutter. 

After  setting  a  target  as  desired,  click  on  another  target  and  set  its  characteristics. 
Continue  to  set  target  characteristics  until  all  are  set  as  desired.  Then  click  on  OK. 


Note  that  these  target  characteristics  set  as  described  above  are  not  saved 
until  the  configuration  is  saved  (on  the  scenario  configuration  screen). 
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External  Conditions  (Scenario  Configuration  screen) 

The  author  can  establish  additional  conditions  on  the  Scenario  Configuration  screen 
(Figure  2).  To  make  this  screen  appear  (or  disappear),  press  the  s  key  (for  scenario), 
then  set  the  following  conditions: 

Atmospheric  Conditions 

•  Ceiling  —  the  altitude  above  which  targets  cannot  be  seen,  during  daytime. 

•  Visibility  —  the  distance  beyond  which  targets  cannot  be  seen,  during  daytime. 

Own  Shin  Svsiem  Readiness,  the  operability  of  own  ship’s  transmitter  and  receiver. 
Limited  Range  means  transmitter  or  receiver  has  an  effective  range  of  10  miles. 

T.oca1  time  (24-hour  clock)  at  the  start  of  the  problem,  which  affects  ability  to  visibly 
observe  targets,  and  possible  presence  of  commercial  airliners,  per  their  schedules. 

Termination  Conditions 

The  author  can  specify  what  causes  an  exercise  to  terminate.  The  four  variables  that  can 
be  used  to  terminate  exercises  are: 

A.  Elapsed  time,  in  seconds.  Enter  a  large  number  (like  9999)  if  elapsed  time  is  not  to 
be  considered  in  terminating  a  problem. 

B.  Own  ship  fires.  A  check  mark  indicates  that  this  variable  is  part  of  the  termination 

condition. 

C.  Own  ship  fired  upon.  A  check  mark  indicates  that  this  variable  is  part  of  the 

termination  condition. 

D.  Range  of  nearest  threat.  Enter  miles,  to  one  decimal  place,  if  this  variable  is  part  of 
the  termination  condition. 

And/Or  selection.  If  more  than  one  of  the  above  four  variables  has  been  set,  select  the 
And  button  or  the  Or  button  to  specify  whether  just  one  or  all  specified  conditions  are 
required  to  terminate  the  problem. 

Example: 

If  elapsed  time  is  set  to  4(X),  B  is  checked,  C  is  not  checked,  D  is  1,  and  the  OR  button 
is  checked  (terminate  when  A  or  B  or  D  is  true),  the  problem  will  terminate  when 
elapsed  time  reaches  400,  or  when  own  ship  fires,  or  when  the  range  to  the  nearest 
hostile  is  1. 

Data  File  Write  Interval. 

The  author  can  specify  how  often  the  target  data  will  be  written  to  file,  thereby  affecting 
the  size  of  the  output  file.  If  a  short  time,  such  as  1  or  2  seconds  is  specified,  the 
system  will  attempt  to  update  the  simulation  and  write  to  file  as  often  as  requested, 
however  the  speed  of  the  host  computer  and  the  number  of  targets  involved  in  the 
scenario  might  prevent  the  system  from  updating  as  rapidly  as  requested.  The  output 
file  indicates  the  time  at  which  the  targets  were  updated,  so  the  author  can  determine  if 
the  system  is  able  to  meet  the  request,  on  a  particular  host  computer. 
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Scheduled  Maneuvers 

Scheduled  maneuvers  are  changes  in  speeds,  headings,  and  altitudes  of  various  targets 
that  are  pre-ordained,  i.e.,  they  are  carried  out  regardless  of  actions  taken  by  the  user 
of  the  simulation.  This  allows  the  developer  of  an  exercise  to  create  a  wide  variety  of 
actions  that  are  not  under  the  control  of  the  CIC  decision-maker. 

Defining  Scheduled  Maneuvers 

Scheduled  maneuvers  by  ships  and  aircraft  may  be  specified  independently  of  the 
scenario  configuration.  Scheduled  maneuvers  are  changes  in  heading,  speed,  or 
altitude,  over  some  time  period,  of  various  ships  or  aircraft.  Clutter  targets  cannot  be 
maneuvered. 

Each  set  of  defined  maneuvers  is  saved  in  a  file,  so  any  particular  scenario  (set  of  initial 
and  external  conditions)  could  be  run  with  different  maneuvers.  The  author  can  specify 
maneuvers  in  two  alternate  ways; 

1.  by  using  the  fly-by-wire  controls  to  change  headings,  speeds,  and  altitudes  as  a 
scenario  runs;  or 

2.  by  editing  a  text  file  that  specifies  the  maneuvers  of  various  craft. 

Since  the  first  of  these  techniques  produces  a  text  file,  the  two  techniques  can  be  used 
in  combination  as  well,  allowing  the  author  to  initially  demonstrate  maneuvers  with 
the  displayed  controls,  but  make  minor  corrections  directly  in  the  resulting  text  file  if 
desired. 

Specifying  Scheduled  Maneuvers  with  the  Fly-by-Wire  Controls 

To  specify  maneuvers  during  a  problem  do  the  following  in  authoring  mode: 

1.  Set  up  any  initial  conditions  desired,  save  the  configuration  if  desired,  and  click  on 

the  Begin  button. 

2.  When  the  simulation  reaches  a  point  at  which  a  maneuver  is  desired,  click  on  the 

Pause  button. 

3.  Press  the  f  key  to  display  the  fly-by-wire  controls. 

4.  Select  the  target  to  be  maneuvered,  if  it  is  not  already  selected. 

5.  Slide  the  Time  control  to  display  the  time  period  over  which  the  maneuver  is  to  take 
place  (this  must  be  greater  than  0).  A  change  of  heading  that  requires  15 
seconds  would  be  indicated  by  sliding  the  Time  control  to  display  15. 

6  Slide  the  Heading,  Speed,  or  Altitude  control  to  the  desired  new  value,  and  release 
the  mouse.  If  desired,  change  one  or  more  of  the  three  target  characteristics  (it  is  not 
necessary  to  reset  the  Time  slider  unless  a  second  change  should  take  a  different 
time).  No  visual  response  will  be  seen  in  the  selected  target  at  this 
time,  since  the  problem  is  paused. 

7  Resume  the  problem  (the  fly-by-wire  box  ean  be  left  on-screen,  or  removed  by 
pressing  f  again),  and  note  that  the  maneuvered  target  changes  to  the  limit  requested, 
in  the  time  specified. 
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8.  Repeat  steps  3  through  7  to  specify  as  many  maneuvers  as  desired.  There  is  no 
requirement  that  one  target’s  maneuver  be  completed  before  another  is  specified. 


9.  Stop  the  problem. 


At  this  point,  all  maneuvers  that  were  specified  via  the 
controls  have  been  written  to  a  data  file  named  flightPlan. 


10.  Before  running  another  exercise,  rename  the  flightPlan  file  to  some  other  name  of 
your  choosing  (running  the  simulation  again  will  wipe  out  the  previous  file).  If 
desired,  you  can  make  direct  text  edits  to  the  file  by  referring  to  the  following 
section.  This  is  the  easiest  way  to  modify  an  existing  maneuvering  file. 

11.  Test  the  maneuvers  by  Getting  the  newly  named  flight  plan  on  the  Scenario 
Configuration  screen,  and  running  the  simulation.  The  previously  recorded 
maneuvers  will  be  repeated. 


Specifying  Scheduled  Maneuvers  in  a  Text  File 

Any  number  of  text  files  can  be  created  to  specify  scheduled  maneuvers.  The  files  can 
be  copies  of  the  flightPlan  file  created  via  the  fly-by-wire  controls,  as  described  above, 
or  they  can  be  created  from  scratch  using  a  text  editor.  The  format  of  the  file  is  as 
follows: 

First  line.  The  first  line  in  the  file  is  not  used,  but  there  must  be  a  first  line  that  contains 
some  text.  A  good  use  of  this  line  is  to  state  what  the  file  describes. 

Data  Lines.  The  remaining  lines  in  the  file,  except  for  the  last  line,  contain  the 
maneuvering  data,  one  line  per  maneuver,  in  the  following  format. 


Start 

Time 

T 

# 

Attribute 

Attribute 

Value 

Time 

Interval 

0016 

01 

h 

00180 

10 

0036 

01 

s 

00060 

05 

0050 

02 

a 

02250 

20 

Characters  1  through  4:  The  time,  in  seconds,  at  which  the  maneuver  is  to  start. 
Characters  5  through  6:  The  target  number  involved  (the  target’s  T  number). 
Character  7 :  Enter  h  for  heading,  s  for  speed,  a  for  altitude  change 

Characters  8  - 12:  The  ending  value  for  the  heading,  speed,  or  altitude 

Characters  13-14:  The  duration,  in  seconds,  required  to  execute  the  maneuver. 

T  .ast  line.  The  last  line  must  contain  ‘end’. 

Example  Maneuvering  File: 

authored  maneuvers 

001601h0018010 

003601s0006005 

005002a0225020 

end 

Here,  the  first  data  line  says:  Change  the  heading  of  target  01  to  180  over  10  seconds, 
starting  16  seconds  into  the  problem. 
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Retrieving  Scheduled  Maneuvers 

As  an  author,  you  can  invoke  any  existing  file  of  specified  maneuvers  by  Getting  a 
Flight  Plan  on  the  Scenario  Configuration  screen  (click  on  the  Flight  Plan  name  box, 
key  in  the  name  of  an  existing  flight  plan  file,  and  press  Enter).  When  an  exercise  is 
started,  the  system  will  automatically  produce  the  specified  maneuvers.  You  could  then 
change  scenarios,  but  leave  the  maneuvering  file  the  same,  and  click  on  Begin  again. 
The  initial  conditions  would  change,  according  to  the  new  scenario,  but  the  maneuvers 
would  be  the  ‘same’,  i.e.,  the  limits  specified  would  be  achieved. 

If  you  do  not  want  any  maneuvers  to  be  performed  during  a  problem  run,  as  an  author, 
clear  the  Flight  Plan  box  by  clicking  in  it,  then  pressing  Return.  All  problems  run,  as  an 
author,  will  then  involve  no  maneuvers. 


To  invoke  maneuvers  for  experimental  participants,  include  maneuvering  file 
names  in  the  SessionPlan  file,  as  described  next. 


The  Session  Specification  File 

An  experimental  session  is  specified  in  an  ASCII  file  named  SessionPlan  (nirte 
capitalization  of  file  name).  This  file  lists  predefined  configurations  which  form  the 
basis  of  exercises.  Optionally,  it  can  invoke  previously  defined  scheduled  maneuvers. 

Line  1. 

If  problems  are  not  to  be  generated  randomly,  the  first  line  can  contain  any  text  that  is 
useful  in  identifying  the  particular  file  when  it  is  printed.  This  line  is  required. 

The  second  line  indicates  the  preferences  for  a  session.  Six  digits  are  entered: 

Digit  1:  Replay  allowed  by  anyone? 

1  means  allow  Replay  by  experimental  participants,  as  well  as  authors 

0  means  allow  Replay  only  by  author 

Digit  2:  Pause  allowed  by  anyone? 

1  means  show  the  Pause  button  regardless  of  the  user’s  name. 

0  means  show  the  Pause  button  only  if  user  is  author 

Digit  3:  Unused  -  enter  0 

Digit  4:  Time  Warp  allowed  by  anyone? 

1  means  respond  to  Time  warp  conunand  (t  entry)  from  anyone 
0  means  only  respond  to  Time  Warp  command  from  author . 

Digit  5 :  Knowledge  of  results  displayed  at  end  of  problems? 

1  means  do  allow  user  to  learn  true  target  identities  at  the  ends  of  problems 
0  means  do  not  provide  true  target  information  at  the  ends  of  problems 

Digit  6:  Performance  score  displayed  at  end  of  problems? 

1  means  do  display  a  score  at  the  end  of  each  problem. 

0  means  do  not  display  a  score  at  the  end  of  each  problem. 
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If  digit  6  is  1,  the  next  line  in  the  SessionPlan  file  must  provide  a  set  of  weights  to  use 
in  computing  the  score,  as  described  in  the  section  Scoring. 

The  author  can  always  replay  problems,  pause/resume  problems,  and  warp  time.  The 
preferences  line  allows  the  experimenter  to  provide  these  options  to  experimental 
participants,  if  desired. 

Following  Lines  r 

The  remaining  lines  in  the  SessionPlan  file,  except  for  the  last  line,  list  names  of 
predefined  configurations  and,  optionally,  scheduled  maneuvers,  as  described  later.  If 
the  first  line  of  the  file  does  not  call  for  random  problem  generation,  the  system  will 
produce  exercises  using  the  listed  configinations  in  order.  In  any  case,  problems  end 
when  the  configuration’s  problem  termination  condition  has  been  met. 

The  last  line  of  the  file  must  be  the  word  end. 

Example  SessionPlan. 

General  Plan  1  (problems  will  be  generated  in  the  fixed  sequence  listed  below) 
010110  (the  preferences  for  the  session,  with  no  scoring) 

MyScenariol  (the  name  of  the  first  exercise,  or  configuration) 

SingleAttack  (the  name  of  the  second  exercise,  or  configuration) 

Of  f  Course  (the  name  of  the  third  exercise,  or  configuration) 

Terrorists  (the  name  of  the  final  exercise) 

end  (end  of  file) 

The  second  line  specifies  these  preferences: 

Replay  only  by  authors;  anyone  may  pause/resume;  no  machine  data  written;  anyone 
may  warp  time;  do  allow  user  to  learn  true  target  identities  at  problem  end;  and  do  not 
display  a  performance  score  at  the  end  of  each  problem. 

Automatic  Problem  Generation 

Problems  can  be  generated  automatically,  either  in  a  systematic  progression  of 
situations,  or  in  a  random  fashion.  In  either  case,  the  automatically  produced  problems 
are  variations  on  predefined  configurations.  The  six  variables  manipulated  are  these: 

•  time  of  day,  2  possible  conditions  (14:00  and  22:00). 

•  radar  clutter  conditions,  3  possible  conditions  (none,  moderate,  heavy) 

•  own  ship’s  equipment  operability 

transmitter,  4  possible  conditions  (OK,  failed,  inteimittenti  limited  range) 
receiver,  4  possible  conditions  (OK,  failed,  intemuttent,  limited  range) 

•  atmospheric  conditions 

ceiling,  5  possible  conditions  (1000;  5,000;  10,000;  25,000;  and  100,000  feet) 
visibility,  5  possible  conditions  (30, 20, 10, 5,  or  1  mile) 
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These  provide  for  2400  different  problems  per  configuration.  Target  characteristics  (the 
number  and  types  of  targets,  their  speeds,  headings,  etc.)  are  not  altered.  Thus,  a 
configuration  can  be  simple  or  complex,  owing  to  the  number  and  types  of  targets,  yet 
it  can  be  made  materially  more  or  less  difficult  by  the  values  selected  for  the  variables. 

When  a  problem  is  generated  with  no  radar  clutter,  none  of  the  clutter  targets  specified 
in  the  basic  configuration  are  displayed.  Under  moderate  conditions,  half  of  the  clutter 
is  shown.  Under  heavy  clutter,  all  the  active  clutter  targets  of  the  configuration  are 
displayed.  Thus  the  maximum  amount  of  clutter  is  determined  within  the  configuration. 
If  a  configuration  has  no  active  clutter  targets,  therefore,  there  will  be  no  clutter  targets 
displayed  regardless  of  the  clutter  conditions  being  used  in  automatic  problem 
generation.  This  approach  allows  the  experimenter  to  custom-position  clutter  targets,  to 
either  simplify  or  complicate  a  problem. 


It  is  recommended  that  at  least  four  clutter  targets  be  provided  if  problems 
will  be  generated  automatically,  so  that  all  problems  will  be  different. 


Random  Problem  Generation 

To  generate  problems  randomly,  over  all  the  configurations  listed  in  the  SessionPlan 
file,  make  the  first  line  in  the  SessionPlan  file  read  as  follows; 
randomize  <number  of  problems>  <seed> 

where  <number  of  problems>  is  the  total  number  of  problems  to  generate  and  <seed> 
is  either  zero  or  some  positive  integer.  For  example: 
randomize  5000  12345 

The  number  of  problems  can  be  any  integer.  If  seed  is  zero,  the  system  will  initialize 
random  number  generation  using  the  system  clock,  thus  the  sequence  of  problems  is 
not  repeatable  from  one  session  to  another.  If  seed  is  not  zero,  the  system  will  initialize 
the  random  number  generator  using  seed,  thus  the  problems  will  be  generated 
randomly,  but  in  a  repeatable  manner.  Random  selection  is  with  replacement,  but  the 
system  never  selects  the  same  configuration  twice  in  a  row. 

Whenever  problems  are  generated  randomly,  the  system  creates  a  file  named 
scratchFile.  This  file  can  be  removed  anytime  sessions  are  not  in  progress. 

Example; 

randomize  3500  5432  (randomly  generate  3500  problems,  with  seed  5432) 
010100 
MyScenariol 
SingleAttack 
Of  fCourse 
Terrorist3 
end 

Sequential  Problem  Generation 

Problems  can  also  be  generated  in  a  sequential  fashion,  each  being  a  systematic 
variation  of  its  basic  configuration.  To  generate  problems  sequentially,  add  the  number 


26 


of  problems  to  be  generated  to  any  configuration  named  in  the  SessionPlan  file  (add  1 
space  then  the  number  of  problems).  Example: 


Session  Plan  2 
010100 

MyScenariol  20 
SingleAttack  8 
end 


(problems  not  generated  randomly) 
(preferences;  no  scoring) 

(run  20  problems  with  this  configuration) 
(then  run  8  problems  with  this  configuration) 


Specifying  Scheduled  Maneuvers  in  the  Session 

To  effect  scheduled  maneuvers  during  a  problem,  add  the  symbol  ‘+’  and  a  scheduled 
maneuver  file  name  to  any  configuration  line  (no  embedded  blanks).  For  example,  the 
following  SessionPlan  file  calls  for  making  the  maneuvers  specified  in  the  file  scary 
on  the  first  two  problems,  and  the  maneuvers  from  sneaky  on  the  last  10  problems: 


Session  Plan  3 
010110 

MyScenariol+scary  (run  MyScenariol  with  scary  maneuvers,  once) 

Off  Course  5  (run  OffCourse  with  no  maneuvers,  with  5  variations) 

Terrorist! +sneaky  10  (run  Terrorists  with  sneaky  maneuvers,  10  variations) 
end 


Replaying  Exercises 

The  author  can  always  replay  completed  exercises,  and  experimental  participants  may 
do  so  if  the  preferences  in  the  SessionPlan  file  allow.  The  option  exists  to  either  replay 
the  just-completed  exercise,  or  any  other  previouslycompleted  exercise.  Thus,  the 
replay  capability  provides  a  way  for  an  instructor  to  ‘demonstrate’  expert  performance 
and  have  others  observe  that  captured  performance  at  another  time  and  place. 

To  replay  a  problem  do  this: 

a.  Upon  completion  of  a  problem,  press  the  ‘r’  key,  and  observe  the  replay  box. 
Replay:  Previous  Problem  I 


b.  To  replay  an  exercise  other  than  the  previous  one,  key  in  the  exercise  name  (click  on 
Previous  Problem,  key  in  the  name  of  a  file  that  contains  the  data  for  a  previously 
completed  exercise,  press  Enter).  Otherwise,  proceed  to  step  c. 

c.  Press  Begin,  and  watch  the  problem  play  out  as  just  performed.  You  will  observe  a 
message  that  indicates  each  action  performed  by  the  user,  and  you  will  see  the  mfluence 
of  that  action  on  the  simulation. 


Replay:  Previous  Problem 

Hook  target  1122  _ _ _ 

Problems  may  be  replayed  multiple  times  by  pressing  Begin  with  the  replay  box 
visible.  Problems  may  be  Paused  during  replays,  if  desired.  To  start  a  new  problem, 
press  the  r  key  to  make  the  replay  box  disappear,  then  click  on  Begin. 
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Scoring  the  User’s  Performance 

To  display  a  performance  score  at  the  end  of  each  exercise,  set  digit  6  of  the  preference 
line  to  “1”.  The  performance  score  is  calculated  automatically  by  the  simulation  system, 
as: 

score  = 

wl 

+  w2  *  closest  hostile  target 

-  w3  *  firings  on  friendly  targets 

-  w4  *  firings  on  hostile  targets  that  would  heed  warnings 

-  w5  *  warnings  at  level  1  issued 

-  w6  *  warnings  at  level  2  issued 

-  w7  *  warnings  at  level  3  issued 

-  w8  *  warning  shots  fired  at  friendly  craft 

-  w9  *  warning  shots  fired  at  hostile  craft 

-  wlO  *  illuminations  of  friendly  craft 

-  wl  1  *  iUuminations  of  hostile  craft 

-wl2  *  number  of  attacks  by  hostile  craft  (0  or  1) 

where  the  coefficients  wl  through  wl2  are  weights  that  apply  to  scoring  during  the 
session.  Any  of  the  weights  may  be  set  to  0. 

If  digit  6  of  the  preference  line  in  the  SessionPlan  file  is  “1”,  then  the  line  following 
the  preferences  line  must  supply  the  weights,  a  36-digit  number,  representing 
twelve  3-digit  weights,  e.g., 

050020050020000002003020005010000100 

The  following  is  an  example  SessionPlan  file  calling  for  scoring: 

randomize  250  0  (generate  250  problems  randomly) 

010101  (preferences;  scoring  enabled) 

025020020050000002003020005025000100  (scoring  weights) 

MyScenariol 

Of fCourse 

Terrorist2 

end 

The  Scoring  Algorithm 

The  primary  objectives  of  the  exercise  are  to  minimize  threat  to  own  ship  from  other 
craft  while  avoiding  inappropriate  defensive  actions.  Secondarily,  the  more  skilled 
decision-maker  will  limit  intrusive  threats  or  warnings  to  situations  deseiying  them, 
while  less-skilled  decision-makers  may  employ  such  actions  inappropriately.  The 
structure  of  the  scoring  algorithm  is  set  up  to  recognize  both  the  primary  and  secondary 
factors. 

The  scoring  algorithm  provides  the  experimenter  considerable  flexibility  in  weighting 
various  actions.  Its  basic  structure  provides  the  ability  to  begin  an  exercise  with  a 
constant  score  (wl),  to  add  to  this  constant  according  to  the  user  s  ability  in  keeping 
hostile  craft  away  (w2),  and  to  subtract  from  this  according  to  the  occurrence  of 
undesirable  events.  By  assigning  proper  weights,  the  experimenter  can  discourage 
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ovenise  of  warnings  (including  illuminations),  even  though  issuing  of  warnings  is  not 
inherently  negative.  In  essence,  warnings  can  be  employed  at  some  ‘cost’  as  an 
investment  to  keep  the  score  high  by  avoiding  approach  or  attacks  by  threatening  craft 
or  taking  inappropriate  defensive  measures.  The  ‘costs’  associated  with  contacting 
land-based  towers  or  calling  for  visual  identifications  are  not  included  in  the  score. 
These  actions,  if  overused,  consume  the  user’s  time  and  attention,  but  if  used  properly 
can  assist  in  conducting  the  task  well. 

Specifying  Commercial  Air  Routes 

The  simulation  provides  six  commercial  air  routes,  shown  as  dotted  orange  lines  when 
the  user  sets  the  Commercial  Air  Routes  check  box  in  the  Display  section  to  checked. 
The  author  can  control  which  of  the  six  air  routes  are  displayed  during  authoring  by 
checking  the  routes  desired  on  the  Scenario  Configuration  Screen.  The  figure  below 
provides  the  numbers  of  the  six  routes  between  the  six  airports. 

In  general,  increasing  route  numbers  relate  to  increasingly  threatening  courses.  The 
selection  of  air  routes  is  independent  of  scenario  configuration,  i.e.,  any  configuration 
can  be  run  with  any  assortment  of  commercial  air  routes. 

The  experimenter  may  call  for  any  mix  of  the  six  routes  to  be  involved  in  a  problem, 
using  an  input  line  starting  with  the  word  routes,  within  the  SessionPlan  file.  The 
following  is  an  example: 
routes  001011 

This  particular  input  causes  air  routes  3, 5,  and  6  to  display  when  the  air  routes  box  is 
checked  by  the  user.  The  input  line  must  be  exactly  as  shown,  with  one  space 
following  the  word  routes,  then  6  digits  that  are  0  or  1.  Authors  are  responsible  for 
setting  up  the  eommercial  airliners  to  follow  the  routes  or  not,  as  they  like. 


Multiple  routes  input  lines  can  be  embedded  in  the  SessionPlan  file.  Each  one 
establishes  the  air  routes  that  will  be  shown  (when  requested)  until  the  next  routes  input 


29 


line,  if  any.  The  first  routes  input  line  must  come  somewhere  after  the  preferences  line 
and  its  following  weights  line,  if  any.  The  following  is  an  example: 


Plan  5 

010111  (preferences) 

025020020050000002003020005025000100  (scoring  weights) 
routes  111000  (enable  only  commercial  air  routes  1,  2,  and  3) 

MyScenariol+scary  (run  MyScenariol  with  scary  maneuvers,  once) 

routes  100001  (enable  only  commercial  air  routes  1  and  6) 

Off  Course  5  (run  OffCourse  with  no  maneuvers,  in  5  variations) 

Ter r or i s  1 3 + sneaky  1 0  (run  Terrorists  with  sneaky  maneuvers,  10  variations) 
end 


Thus,  in  the  foregoing  SessionPlan  file,  routes  1, 2,  and  3  are  enabled  (displayable)  for 
the  first  problem,  while  routes  1  and  6  are  enabled  for  the  following  fifteen  problems. 

The  system  enables  all  six  routes  by  default  at  the  start  of  an  experimental  session,  in 
case  problems  are  run  with  no  preceding  routes  specification. 


Specifying  Airport  Names 

The  author  can  set  the  names  of  the  six  airports  involved  in  commercial  air  travel  for  a 
session.  To  do  this,  create  a  text  file  named  portNames,  entering  one  name  per  line. 

The  names  are  assigned  in  the  order  Usted  to  airportA,  airportB . airportF  as  shown 

in  the  preceding  diagram. 

Example: 


Milwaukee 

San  Francisco 

Gerberville 

Paris 

Nome 

Akron 

Setting  Airport  Names  and  Display  of  Air  Routs  During  Authoring 

The  author  can  set  the  names  of  airports  and  cm  control  the  display  of  air  routes  during 
authoring  by  making  settings  on  the  Scenario  Configuration  scene.  These  settings, 
however,  are  not  saved,  nor  do  they  affect  experimental  runs. 


Printing 

The  simulation  sereen  may  be  printed  at  any  time  using  the  print  menu  item,  however 
the  proper  print  command  may  vary  from  one  installation  to  another.  Each  user  should 
key  in  whatever  Unix  print  command  works  for  the  system  involved. 

The  default  print  line  works  for  SCO  Unix. 

For  Novell  UnixWare  users,  override  the  default  print  command  with  this: 

Ip  -o  nobanner  -Tpostscript 
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Machine  Learning  Mode 

The  CIC  simulation  can  be  set  up  to  communicate  bi-directionally  with  a  machine 
learning  program,  hosted  either  in  the  same  platform  or  over  a  network.  The  ‘setup’  is 
accomplished  simply  by  entering  the  name  ‘machine’  to  the  CIC  system  when  it  is 
started. 

Two  data  files,  MLData  and  Status,  are  used  for  inter-processor  communication.  File 
MI  .Data  is  used  by  CIC  to  inform  the  machine  learning  system  about  the  progress  of  a 
scenario,  and  it  is  used  by  machine  learning  models  to  communicate  decisions  back  to 
CIC.  The  Status  file  is  used  to  control  and  mark  who  has  control  of  the  process.  When 
CIC  is  ready  to  turn  control  over  to  machine  learning,  it  writes  “GOML”  into  Status 
(this  will  be  the  only  record  in  the  file).  When  machine  learning  is  ready  to  turn  control 
back  to  CIC  (after  writing  out  its  decision  to  the  MLData  file),  it  writes  “GOCIC”  as  the 
only  record  in  Status. 

Data  Communicated  to  the  Machine  Learning  System 

In  machine  learning  mode  the  CIC  system  communicates  four  kinds  of  data  to  the 
outside  world:  1)  initial  conditions,  2)  periodic  updates  which  provide  current 
information  about  the  simulated  world,  3)  actions  performed  by  other  simulated  people 
in  the  scenario,  and  4)  an  end-of-problem  marker. 

Tnitial  Conditions.  At  the  Start  of  each  problem,  the  CIC  system  writes  out  to  the 
MLData  file  a  complete  image  of  the  starting  conditions  of  the  scenario.  This  block  of 
data  starts  with  the  record  “MLData”,  and  ends  with  the  specifications  for  each  active 
target,  plus  clutter,  in  the  exercise.  Note  that  this  inital  header  data  does  not  start  with 
the  c(ie  “01”  that  precedes  all  subsequent  periodic  updates. 

TTpHatps.  Every  few  seconds  during  the  simulation  the  CIC  system  writes  out 
to  the  MLData  file  a  complete  ‘snapshot’  of  the  scenario  at  that  instant  TOs  file  write  is 
done  each  time  the  graphical  display  is  updated,  i.e.,  the  machine  learning  system  will 
receive  the  same  information,  in  data  form,  that  a  human  operator  would  perceive 
visually.  The  data  format  of  the  MLData  file  is  that  described  under  Periodic  Updates, 
above  (each  periodic  update  starts  with  a  record  “01”  followed  by  the  update  time). 

Artinns  of  Others.  The  CIC  system  also  broadcasts  the  performance  of  actions  by 
people  oflier  than  the  decision-maker.  These  actions  are: 


Action 

Code  1 

the  warned  target  replies 

the  crew  returns  a  visual  identification 

08 

a  land-based  tower  responds  to  a  query 

10 

Other  characters  follow  these  codes,  giving  the  time  of  occurrence,  and  if  appropriate 
the  track  number  of  the  acting  target.  See  section  Replies  and  Target  Actions  for  the 
complete  formats.  If  the  machine  learning  system  needs  to  know  exactly  what  a  warned 
target  says  when  it  replies,  it  can  refer  to  the  ASCII  file  which  generated  that  text  (file 
CICDescriptions),  in  reference  to  the  configuration  being  run  (which  is  specified  in  the 
configuration  file). 
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End-of-Prohlem  Marker.  At  the  conclusion  of  each  problem,  the  CIC  system  writes 
the  code  “99”,  followed  by  the  total  elapsed  exercise  time,  and  the  performance  score, 
to  MLData.  At  this  point,  the  machine  learning  system  can  write  out  any  data  files  it 
uses,  and  it  can  prepare  to  start  the  next  problem.  When  it  is  ready  to  proceed,  it  should 
write  action  code  “00”  to  MLData,  then  write  “GOCIC”  to  file  Status. 

Turn  Taking 

At  startup,  the  machine  learning  system  should  write  “WAIT’  to  the  Status  file,  then 
monitor  that  file  until  it  contains  the  record  “GOML”.  Thus,  the  QC  system  bp  the 
first  real  ‘turn’.  The  initial  data  that  CIC  writes  to  the  file  MLData  describes  the  initial 
scenario  conditions.  Following  each  write  to  MLData,  the  CIC  system  pauses  until  the 
machine  learning  system  responds.  During  this  pause,  there  is  no  activity  in  the 
simulation  whatsoever,  and  passage  of  time  is  ignored. 

The  machine  learning  system  can  detect  that  new  information  is  available  for  analysis  if 
the  first  and  only  record  of  the  Status  file  is  “GOML”.  In  this  case,  the  machine 
learning  system  can  read  in  the  complete  MLData  file,  and  it  can  take  as  much  time  as 
necessary  to  digest  the  situation.  Then  it  should: 

1.  write  out  a  single  record  to  the  MLData  file,  indicating  its  decision, 
and  then 

2.  write  the  record  “GOCIC”  to  the  Status  file. 

As  soon  as  the  machine  learning  system  writes  the  “GOCIC”  record  to  the  Status  file, 
the  CIC  simulation  acts  on  any  decision  residing  in  MLData,  and  it  resumes  simulating 
until  it  is  time  to  inform  machine  learning  again. 

Communicating  Machine  Learning  Decisions 

Each  machine  learning  decision  is  represented  via  a  2-character  ASCII  d^ision-code, 
followed  by  a  few  extra  characters  for  action  codes  “02”  and  “03”.  The  action  codes  are 
shown  in  the  table  below  (‘hooked  target’  signifies  the  most  recently  hooked  aircraft  or 
sea  vessel). 


Action 

Plus 

No  action  (continue  with  scenario) 

Hook  a  new  target 

02 

4-character  track  # 

Warn  the  hooked  target 

mam 

level  (1,2,3)  &  channel  (1,2) 

Fire  warning  shots  at  the  hooked  target 

05 

Illuminate  the  hooked  target 

mim 

Request  visual  ID  of  the  hooked  target 

07 

Contact  tower  regarding  hooked  target 

09  1 

Fire  at  the  hooked  target  H 

These  data  are  ASCII  characters. 

Two  action  types,  hook  target  and  warn  target,  require  a  few  extra  digits,  as  explained 
next. 
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Hnnkiny  (Selecting^  Targets.  Prior  to  performing  any  action  involving  a  target, 
the  decision-maker  must  identify,  or  ‘hook’  the  target  to  be  acted  upon.  To  hook  a 
target,  write  a  record  starting  wiA  ‘02’,  followed  by  the  target’s  4-character  track 
number,  e.g.,  021524  means  hook  target  1524.  Then,  at  each  decision  opportunity,  the 
machine  learning  system  can  call  out  an  action  to  take  upon  the  hooked  target.  To  act 
on  another  target,  perform  another  hooking  action,  supplying  the  new  track  number. 

Warning  Targets.  To  warn  the  hooked  target,  write  a  record  starting  with  ‘03’, 
followed  by  the  character  ‘1’,  ‘2’,  or  ‘3’,  signifying  the  warning  level,  and  the 
character  ‘1’  or  ‘2’,  signifying  the  ra^o  channel  (MAD  is  ‘1’,  lAD  is  ‘2’),  e.g., 

0321  means  warn  the  hooked  target  at  level  2,  on  the  MAD  channel 

Ex^ples 

021053  hook  target  1053 

0  5  fire  warning  shots  near  hooked  target 

09  contact  tower  regarding  hooked  target 

0321  warn  the  hooked  target  at  level  2,  on  the  MAD  channel 

60  fire  on  the  hooked  target 

Starting  A  Machine  Learning  Session 

Start  your  machine  learning  system  first.  Then  start  the  CIC  simulation,  entering 
“machine”  as  the  user  name,  and  then  click  on  the  Proceed  button.  All  processing  after 
this  point  is  automatic. 

Your  machine  learning  system  should  follow  these  procedures: 

1.  At  start  up,  write  “WAIT’  to  the  Status  file. 

2.  Monitor  the  Status  file  until  it  reads  “GOML”  or  “STOP”, 

3.  If  STOP,  the  session  is  done.  If  GOML,  compute  a  decision  and  write  out  the 
appropriate  action  code  to  MLData. 

tiien 

4.  Write  “GOCIC’  to  the  Status  file  (one  record,  destructive  write). 

5.  Go  back  to  step  2. 

If  the  machine  learning  system  wants  to  stop,  it  should  write  “STOP”  to  Status  at  step 
3,  then  do  step  4,  then  it  should  wrap-up  its  own  business  and  then  stop.  Alternatively, 
it  could  simply  stop  at  step  3,  leaving  CIC  in  a  waiting  condition. 

Testing  Communications 

To  facilitate  testing  of  a  machine  learning  configuration,  a  second  Rides  program, 
testML,  is  provided.  This  routine  allows  you  to  m^e  decisions  manually  that  are  then 
communicated  to  the  CIC  simulation,  and  it  receives  and  displays  the  first  record  of 
each  data  dump  which  CIC  makes  to  the  MLData  file. 

Using  testML,  you  can  manually  perform  these  actions: 

•  hook  eitiiCT  of  two  targets,  (the  ‘first’  being  whatever  target  happens  to  be  listed 
as  the  first  target  in  the  scenario,  and  the  ‘second’  being  the  target) 

•  warn  the  hooked  target  (level  2  and  the  MAD  channel  are  assumed); 

•  contact  the  tower  about  the  hooked  target; 

•  request  a  visual  ID  about  the  hooked  toget;  and 

•  continue  simulating  (no  action  at  this  time). 
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Your  machine  learning  system  can  invoke  other  actions,  but  these  are  sufficient  to  test 
the  communication  channels  with  CIC. 

Here  is  the  procedure  for  using  testML  with  CIC, 

1.  Launch  testML  and  CIC  in  any  order,  but  don’t  start  either  one. 

2.  Start  testML  by  clicking  on  its  Start  button.  Its  Start  button  turns  red. 

Observe:  Waiting  for  initial  conditions  front  CIC. 

3.  Enter  “machine”  as  CIC’s  user  name,  if  it  is  not  already  there,  and  click  on  Proceed. 

4.  After  5  - 10  seconds,  the  radar  simulation  screen  will  appear,  CIC  will  write  out  the 
initial  conditions  to  l^Data,  and  testML  will  display: 

Initial  Conditions  received;  continue.  ,  .  .  • 

5.  dick  on  the  bottom  button,  labelled  “continue  simulating”.  Each  time  a  decision  is 
indicat^  via  a  radio  button,  the  buttons  will  disappear. 

6.  The  CIC  simulation  will  display  ML  decision:  00  and  it  will  make  its  first  update 

to  the  scenario  and  write  out  a  periodic  update  to  MLData. 

7.  Now  you  will  see  the  first  record  of  the  update  in  testML,  something  like  01  4 
meaning  a  periodic  update  at  4  seconds.  If  you  like,  you  can  bring  up  the  entire 
MLData  file  in  a  text  editor  and  observe  the  full  contents. 

8.  From  this  point  on,  you  may  make  any  of  the  decisions  supported  by  testML  by 
clicking  on  one  of  the  radio  buttons.  Following  each  decision,  CIC  will  display  the 
exact  action  code  it  receives,  it  will  update  the  scenario,  it  will  wnte  out  a  periodic 
update  or  a  response  to  one  of  yoxur  actions  (a  reply  from  a  warned  target,  a  tower, 
or  the  crew  member  making  a  visual  ID),  and  it  will  pause,  waiting  for  another 
decision. 

At  the  end  of  a  problem,  you  will  see  the  code  99  followed  by  the  time.  Click  on 
proceed.  If  your  sessionPlan  file  lists  more  than  one  problem,  CIC  will  start 
running  the  next  problem.  To  end  a  test  session,  click  on  the  testML  Stop  buttom 
While  testML  can  be  restarted  simply  by  clicking  on  the  button  ajgain,  the  CIC 
system  must  be  restarted  from  the  beginning,  i.e.,  at  the  initial  user  identification 
screen. 

Testing  Machine  Learning 

The  machine  learning  system  has  access  to  all  of  the  data  involved  in  a  scenario  (imtial 
conditions,  periodic  updates,  and  actions  by  others),  as  well  as  its  own  decisions. 
Since  execution  time  is  of  no  consequence  during  the  machine  learning  control  phase,  fr 
can  write  out  whatever  data  is  useful  to  fully  document  the  exercise.  Note  that  the  CIC 
system  does  not  write  out  exercise  data  to  any  other  file  than  MLData,  in  machine 
learning  mode. 

If  desired,  experimenters  may  observe  the  scenmo  while  it  is  being  run  in  association 
with  a  machine  learning  system.  For  convenience,  the  CIC  system  displays  each 
decision  that  it  receives  in  the  lower  user  prompt  area,  in  red  letters,  e.g., 

ML  decision  :  021534 


It  is  important  that  no  further  actions  be  taken  via  mouse  on  the  CIC  simulation, 
once  a  machine  learning  session  is  started;  any  mouse  actions  on  the  simulation 
screen  could  lead  to  confusion. 
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Appendix  A 

Targets  Provided 

The  CIC  simulation  is  stocked  with  the  following  targets: 


Target  Type 

aircraft 

surface  vessels 

_ 15 _ 1 

submarines 

clutter 

The  experimenter  may  employ  any  subset  of  these  targets  in  a  particular  exercise,  and 
may  configure  all  aspects  of  each  target,  except  that  target  type  is  fixed  for  each  target. 
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Appendix  B 


Built-in  Delays 

One  of  the  difficulties  in  using  any  complex  man-machine  system  is  Ae  problem  that 
commands,  inquiries,  and  responses  all  consume  time —  there  are  significant  delays  in 
crew  member  responses  to  commands,  and  in  responses  by  targets  to  actions  taken  by 
the  decision-maker.  The  following  lists  the  delays  that  are  intentionally  built-in  to  the 
CIC  simulation  to  maintain  high  realism. 


Defend  Ship 
Illuminate  Target 
respond 
Contact  Tower 
Visual  ID 
target 

Warn  Target 
Fire  Warning  Shots 


15  seconds  to  fire  at  hooked  target,  following  the  order 
45  seconds  for  illuminated  target  to  respond,  if  it  does 

30  seconds  for  tower  to  respond. 

10  seconds  for  crew  to  attempt  identification  of  hooked 

20  seconds  for  target  to  respond,  if  it  does  respond 
30  seconds  to  fire  shots,  following  the  order 
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Appendix  C 

Summary  of  Key  Commands 

The  following  keys  can  be  pressed  by  the  author  to  effect  various  authoring  functions; 

c  Shows/hides  the  target  configuration  box;  used  to  configure  selected  targets, 
f  Shows/hides  the  fly-by-wire  controls;  used  to  set  target  speed,  heading, 
altitude. 

m  Used  to  move  the  selected  target;  click  at  the  new  position  while  holding  down 
m. 

r  Shows/hides  the  exercise  Replay  box. 
s  Shows/hides  the  Scenario  configuration  screen, 
t  Shows/hides  the  time  warp  confrol;  used  to  accelerate  testing. 

V  Shows/hides  inactive  targets,  for  the  current  configuration. 

X  Shows/hides  the  target  debriefing  box.  _  _ 

The  experimenter  can  also  allow  study  participants  to  use  the  r  and  t  commands. 
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Appendix  D 

Supplied  Configurations 

The  following  configurations  are  supplied  with  the  CIC  simulation  software: 


Nature  of  the  Configuration 

configl 

All  targets  are  active  and  arranged  by  target 

type  _ _ _ 

config2 

Approximately  half  of  the  targets  are  active 

configS 

No  targets  are  active 

config4 

A  commercical  airliner  approaching 

configS 

These  configurations  simply  provide  helpful  starting  points  to  create  custom 
configurations.  If  a  configuration  will  employ  most  of  the  available  target  types, 
configl  provides  a  useful  basis.  If  very  few  targets  will  be  involved,  start  with  configS, 
and  move  the  targets  desired  onto  the  radar  screen.  Config4  and  configS  provide 
samples  of  configurations  that  could  be  used  for  experimentation. 


In  configuration  configl,  config2,  and  configS,  the  targets  are  set  up  as  follows: 


Tracks 

Character 

Will 

Fire? 

Will 

Heed? 

■HKHUirJltiaglll 

small  private  aircraft 

no 

1043,  45,  47,  49, 

51 

commercial  airliner 

no 

yes 

1053,  55,  57,  59 

no 

yes 

1061,  63  65 

yes 

yes 

1  iT*U  1 1 P4 1 'll  1 1  hi  1  k*!*. 

yes 

no 

1073 

comm’l  airliner  w/  no 
radio 

no 

not  to  radio 

1122 

friendly  submarine 

no 

no 

1123 

hostile  submarine 

yes 

1124 

hostile  submarine 

yes 

no 

1234,  44,  54 

no 

1236,  46,  56 

yes 

[no - 

1238,  48.  58 

1  U.S.  Navy  ship 

no 

1240,  50,  60 

no 

yes 

1242,  52,  62 

1  hostile  ship 

yes 

yes 

These  characteristics  exist  in  relation  to  the  CICDescription  file,  which  has  these  entries 
(inidividual  users  of  the  software  may  be  using  different  descriptions  in  their  file): 
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Descripton 


